This invention pertains generally to gaming systems. More particularly, the present invention relates to a method and apparatus for providing high performance, incremental and large upgrades, and a consistent game development API for gaming cabinets, both existing and new.
Gaming industry cabinets are fairly standardized as to general configuration. This is partly due to the needs of the casinos, who want to fit the maximum number of gaming devices into a given amount of floor space. It is also due to the physical needs of players, who need a certain minimum amount of cabinet area in front of them to play the game while not crowding their fellow players on the next gaming machine. It is also due to the requirements of the game components, encompassing both regulated and non-regulated aspects. Game components include a video monitor or reels, input and output devices (buttons, network interface, voucher or ticket printers, and magnetic strip card readers are typical) together with a main processor board. The main processor board has interfaces to the various input and output devices, and has at least a processor and memory which enables gaming software to be installed and run on the processor board. In most gaming machines the processor board, power supply and other related mechanical and electrical elements are typically co-located near the base of the gaming machine. Disposed there above at proximately chest level of the player is the gaming display, such as the rotatable reel displays in a slot machine or a video monitor for video-based games.
FIG. 1 illustrates a common prior art gaming machine. The gaming machine 100 has a top candle 108, a video screen or reel area 102, player input area 104 (generally having buttons, coin-in and/or bill-in, card reader, and in newer machines a printer), and pull handle 106. Gaming machine 100 has, in its interior, a processor board whose location is generally indicated as 110 (the actual processor board and mounting hardware are on the inside of the cabinet).
The processor board, in addition to have physical mounts such as guides, rails, standoff mounts, board slots, board slides, or board tray, will further have cabinet electronic interfaces, typically at the back of the board (towards the front of the cabinet, from a player's perspective). Processor boards will typically have a set of multi-pin plugs or bus connectors that slide into mating plugs or bus connectors when the processor board is correctly seated in its mounts.
FIG. 2 shows a picture of a prior art processor board 200, in this case a processor board from an IGT® Game King® gaming machine. Shown is the top of the board, with the front of the board facing the bottom of the figure. As is typical, the sides of the board slide into the game cabinet using guide rails in the cabinet, with the cabinet bus or connector interfaces 202 mating to specially positioned and configured plugs in the cabinet.
If the board needs work, the entire processor board is replaced. In addition to a replacement board from the manufacturer (in this case IGT®), there are commercially available replacement boards having the same or nearly the same features, speed, memory capacity, etc., from after market manufacturers. No matter where the board originates from, they follow the same configuration, that is, they consist of a single board that replaces the processor board supplied with the game having similar functionality and the same form. In addition to their physical similarity, they employ a monolithic software architecture; that is, the game-cabinet-specific operating system and specific game software are not a modular, layered design using modern software engineering practices. An example of an aftermarket replacement processor board for the IGT® Game King® gaming cabinet is or was sold by Happ Controls™, 106 Garlisch Drive, Elk Grove, Ill. 60007. It has the same basic physical, electronic, and software architecture as the original.
Upgrade processor boards are also available for some games. The reason for considering upgrade boards is that it may be possible to run newer games in a cabinet already owned by a casino if improvements are made to processor speed, memory, graphic support chips, and other components. Game upgrades interface to some degree with the internal busses of the game cabinet, but require cabinet modifications. Currently available upgraded boards do not fit in the slot used by the original processor board; rather, they must be mounted elsewhere in the cabinet. In addition to requiring the accompanying mechanical fabrication and electrical work, the upgrade boards are a fixed upgrade. That is, if the configuration of the upgraded game itself needs to be upgraded a few years later, you have to purchase and install a completely new upgrade kit which requires going through the same installation problems that were encountered with the original upgrade. This is a significant deterrent to upgrading activity.
In addition, each proprietary processor board as well as upgraded game boards typically uses its own interface to the game software, requiring game rewrites each time a hardware upgrade occurs. This makes gradual or incremental game enhancement prohibitively expensive.
Thus, it would be desirable to provide a game processor that is usable in upgrades in existing cabinets, as well as usable for new game cabinets, that is more cost effective, is easier to install, provides for incremental upgrades itself, and provides more standard interfaces to the game development community.
Furthermore, most gaming systems today are embedded systems. Existing gaming systems typically contain limited resources such as processing power, memory, and program storage. Because of these limitations gaming platform programs have generally been implemented as one monolithic program, where all of the code is compiled into one executable program. Monolithic programs which drive the gaming system typically use interrupts to handle all real-time background activities. These interrupts are driven by the hardware components. The interrupts typically process time critical data and place this data or status information into memory variables which are shared by the main line code. Monolithic programs usually have a series of tasks that need to be performed in the main line code. These tasks might include acting on status information from interrupts, and processing player input and other events that drive the gaming application.
The problem with monolithic programs is that the program must be stored in one media device such as an EPROM, series of EPROMs acting as one media device, flash memory devices, or hard drive. Any modification to the monolithic program requires an update to the program storage device. This means that if a bug is found in a particular core feature, such as paying coins from the hopper, then all game programs must be rebuilt and re-released to the regulatory agencies for approval. A core feature modification such as this can require a gaming manufacturer to re-release hundreds of programs. Each program must be retested and approved by the regulatory agencies causing considerable delays and increased costs to the gaming manufacturer.
Another method that gaming manufacturers have performed in the past, is to separate the media that contains the game paytables from the media that contains the monolithic program. The game paytable is typically a table of pay rates that control how the gaming machine program plays and pays out wins. The benefit to this method is that regulatory agencies do not need to retest a paytable if it does not change. By making a modification to the monolithic program, the paytable media stays the same, allowing the regulators to assume the paytable will work as it did before.
While there are some benefits to this method, there are some very constraining drawbacks. First, the paytable media only contains data tables that drive the execution of the game program. The paytable media does not contain executable code. This means the monolithic game program must contain the core gaming system code along with the game code. The program must support all game code and game variations that can be driven by the paytable data media. It is not feasible for a game program to support hundreds of different game variations due to the limited resources of the embedded system. The paytable media can only be changed to effect changes in the game features or payouts that are already in the game program. It is also very difficult to continually maintain the core gaming modules along with all of the hundreds of game modules in the manufacturers library.
Hence, it would also be desirable to provide a gaming system architecture that solves the foregoing issues, as well as others, with respect to separation of operating system and game media.